In circuit emulation (ICE) has been used by software and hardware developers for a number of years as a development tool to emulate the operation of complex circuit building blocks and permit diagnosis and debugging of hardware and software. Such in circuit emulation is most commonly used to analyze and debug the behavior of complex devices such as microcontrollers and microprocessors that have internal structures that are far too complex to readily model using computer simulation software alone.
FIG. 1 illustrates an exemplary conventional in-circuit emulation arrangement 100 used to model, analyze and debug the operation of a microcontroller device. In this arrangement, a host computer (e.g., a personal computer) 110 is connected to a debug logic 120 which is further connected to a special version of the microcontroller device that has been developed specially for use in emulation. Traditionally, a microcontroller manufacturer would manufacture two versions of any one of its microcontrollers, a special version and a production version. The special version of the microcontroller includes special testing hardware (e.g., scan chain, registers, and the like) for supporting software debugging functions. The special version is only used for the purpose of testing and debugging microcontroller code, where the debugged microcontroller code is eventually loaded in the production version of the same microcontroller to be marketed.
Debugging operation starts with the host computer 110 loading instructions through debug logic block 120 to the special version of the microcontroller 130 where the instructions are executed. Depending upon the application, this operation may be monitored while the special version of the microcontroller 130 is interconnected with the circuitry that is intended to interface a production version of the microcontroller in the finished product under development. Such interconnection -may be via simulation within the host computer 110 or as actual circuitry or some combination thereof. As the circuit is stepped through its operation, the debug logic gathers information about the state of various components of the microcontroller 130 during operation and feeds that information back to the host computer 110 for analysis.
During the course of the analysis, various trace information such as time stamps, register value, data memory content, etc., may be logged in the host computer 110 for analysis and debugging by the designer. Additionally, it is generally the case that various break points can be defined by the designer that cause the program to halt execution at various points in the operation to permit detailed analysis. Other debugging tools may also be provided to enable the user to debug the operation of the circuit.
Typically during the debugging process a designer would prefer to run the microcontroller in as much of a real world situation as possible. Therefore, a microcontroller is installed in a test circuit, which closely resembles the hardware that is to be controlled by the production version of the microcontroller under the test. It is appreciated that the term base station and ICE are used interchangeably herein.
As described above, ICE is a conventional technique for debugging a microcontroller code. A typical ICE includes a production microcontroller used for debugging purposes, a virtual copy of the production microcontroller, which exist in the base station unit, and a host device. The production microcontroller includes a memory, a CPU register, a SRAM, a program counter, and a file register. The host device copies a substantial part of the production microcontroller in the base station, which forms the virtual microcontroller. The base station also includes a memory, a CPU register, a SRAM, a program counter, and a file register.
Debugging process is initiated by software residing in the host device, which loads the microcontroller code in both production microcontroller and the virtual microcontroller. The Production microcontroller and the virtual microcontroller run the microcontroller code in a synchronized process. Synchronization of the microcontroller and the virtual microcontroller requires that the production microcontroller and the virtual microcontroller start running the microcontroller code at the same time, execute the same lines of code sequentially, and if there is a breakpoint in the microcontroller code or if a user halts the execution of the microcontroller code for any purpose, both production and virtual microcontroller encounter the command at the same time. Furthermore, synchronization requires that during the course of debugging the microcontroller code, after execution of each line of the microcontroller code, the memory, the CPU register, and SRAM of the virtual microcontroller and the memory, the CPU register, and SRAM of the production microcontroller have the same value. Furthermore, it is appreciated that the contents of the memory, the CPU register, and SRAM in the production microcontroller are not available to the user while the production microcontroller is executing a code.
Conventional methods used for debugging of a microcontroller code do not check the consistency of a debugging process on real time basis. However, a need exists to ensure the integrity of a synchronized execution of the debugging process while a microcontroller program is being debugged. Furthermore, a need exists to check the consistency of the synchronized debugging process when the production microcontroller and the virtual microcontroller hit a break point or when a user halts the debugging process for any reason. Also a need exist to ensure that the memory contents of the production microcontroller and the virtual memory are a mirror image of one another. The present invention provides a novel solution to these requirements.